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EYE UNDERSTAND An AI system must. 
do more than simply perceive patterns in the 
environment around it. We look at some of 
the problems involved in programming 
computers to make sense of what they see 












A LITTLE PEACH A taste of things to 
come! The ACT Apricot F1e is one of the 
first entries in the impending marketting 
race to provide high-powered and affordable 
machines for the serious home micro user 











PLANNING THE ACTION We take a 


look at two of the best program generators — 
TLO and Sycero — in action 


INTERSTELLAR INTERACTION Now 
you can join Ford Prefect, Zaphod 
Beeblebrox and Arthur Dent in a text-only 
adventure of a lifetime 
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FUNCTIONAL DESIGN This week we 


look at several of LisP’s more important 
functions 
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FROM PROMPT TO PUNCHED CARD 
A weekly glossary of computing terms 
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SET-UP SHOT We begin the programming | 
of our Go game by developing procedures to 1393 
set up the board display 











HOOK LINES There are a variety of useful 


routines made available to the Spectrum 1398 
machine code programmer using the 
Interface 1. We show you how to use them 





RULES OF COMPOSITION We look into 


some aspects of data transmission between a 1386 
computer and an instrument 





INSIDE 
REFERENCE CARD Another section of ACK 


the Commodore 64’s memory map COVER 





COVER GRAPHICS BY IAN McKINNELL ON THE MACINTOSH 
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Because seeing and understanding are such 
integral (and interrelated) factors in the way 
we perceive our environment, we often find 
it difficult to separate the two, which is 
exactly what is needed when programming a 
computer to ‘understand’ what it ‘sees’. 


. si 


. 
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‘Beauty is in the eye of the beholder’, as they say; 
but it should be said that beauty is in the brain of 
the perceiver — or, more accurately, in a complex’ 
chain of neural processes that begins at the back of 
the retina and ends somewhere in the occipital 
cortex of the brain. It is this chain of events that 
physiologists seek to understand and roboticists, 
in some measure, seek to duplicate (for examples 
of the latter see pages 681 and 741). 

Visual perception is such an integral component 
of the way in which we understand our 
environment that we often say ‘I see’ when we 
mean ‘I understand’. Indeed, understanding is the 
key to the challenge of computer vision. Somehow 
the computer must take information supplied by a 
camera, or other light-sensitive device, and realise 
what that information tells it about the state of its 
environment. Acquiring the information is easy — 
the problem is how to interpret it. 











There are three main stages in the process of 
transforming images into meanings: 


1. Picture Processing: Turning a blurred or 
distorted image into a sharper one. (This is a 
relatively simple task to solve.) 

2. Pattern Recognition: Detecting the presence or 
absence of significant features or objects. (This is 
more complex.) 

3. Image understanding: Working out what is 
going on in the real world. (A very complex 
problem.) 


Although true computer vision (Stage 3) has yet to 
be achieved, useful results have been obtained 
from the two initial stages. 


PATTERN RECOGNITION 


Pattern recognition is a challenging task, though 
we find it hard to ‘see’ the difficulties involved. 
Pattern recognisers classify images by matching 
them with a limited set of alternatives, such as the 
letters of the alphabet for optical character 
recognition systems. Typically, they extract 
features by examining parts of the digitised image 
(small groups of pixels). The system can then 
recognise and classify patterns based on the 
presence or absence of certain distinctive features. 
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A Good Fit 

Some pattern recognition 
systems adopt a ‘top-down’ 
approach in which a pattern or 
scene is scanned for the 
presence of a particular object. 
A wire-framed represeniation of 
the object is projected onto the 
screen in various orientations 
until, if the object is present, a 
projection is found that fits the 
Outline of the actual figure. In a 
three-dimensional scene, such 
as that shown here, there are a 


large number of possible 


projections of a wire-framed 
model of the bus that could be 
made before the correct one 
was found 
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The recognition of some features, such as 
diagonal strokes, seems clear to us, but often 
recognition by such systems can result from purely 
arbitrary computations performed on the image 
data. Such systems have important practical uses, 
but they hardly scratch the surface of what we 
mean by vision. 

Historically, there have been two contrasting 
approaches to computer vision as image 
understanding — the top-down or model-driven 
approach and the bottom-up or data-driven 
approach (see page 742). 

Model-driven scene analysis is sometimes 
called ‘controlled hallucination’. The system has an 
internal model of what it is looking for (a double- 
decker bus, let’s say) and it projects that model in 
various orientations onto the picture plane. Then 
it tests for quality of fit between what it has 
‘imagined’ and what is actually there. 

Bottom-up systems scan the image data for 
lines, edges and other tell-tale signs. By doing so, 
they construct a simplified description of the 
image, which is termed a ‘primal sketch’ — a highly 
abstracted data representation. The idea is that by 
stripping away much of the detail, it will be easier 
to compare the sketch with examples from a given 
category of objects stored as reference templates. 

Practical systems tend to employ both top- 
down and bottom-up methods, but until recently 
there were very few learning systems in the field of 
computer vision. They all relied on _ pre- 
programmed intelligence. 

A notable exception is Igor Aleksander’s 
WISARD (Wilkie, Aleksander & Stonham’s 
Recognition Device). It can be taught to make the 
comparatively subtle distinction between a 
smiling and a frowning human face. It can even 
generalise this knowledge to faces it has never seen 
before. WISARD operates in real-time (25 
frames per second), and its commercial success in 
grading chocolates on a moving conveyor belt may 
pave the way for a new generation of ‘seeing 
machines’ that adapt and improve _ their 
performances. 

Very briefly, WISARD works by assigning 
groups of eight pixels at a time (octuples) to 
selected banks of RAM. An octuple is a feature 
detector, and it can be in one of 256 states (0 to 

255) depending on the status of each of the pixels it 
monitors. During the training phase, a 1 is stored at 
the location within its RAM-bank specified by the 
state of the octuple when a particular image is 
present. Later, in the recognition phase, the 
presence of a 1 at the addressed location within 
that octuple’s RAM-bank is evidence that the 
‘taught’ image is again present. 

By using a large number of octuples, or 
discriminators, the system becomes relatively 
impervious to spurious data (‘noisy’ images). 
Aleksander’s system has a 512 by 512 grid for the 
image and over 32,000 octuples. This requires 
about eight million bits (a megabyte) of RAM. 
Only recently have such memories become 
economically feasible. 
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Coco” | Primal Sketches 


6050-6050.5 | Amethod of visual processing has been developed that does not 
an is 7 sane rely on prior knowledge of what the pattern is meant to 
oe represent. The primal sketch (a) extracts boundaries and 
| : | primitive shapes from the image of the toy bear by comparing 
S$ 60495 | adjacent regions. Further extractions from the primal sketch — 
| (b) to (d) — show important groups that assist recognition of the 
original image 












Secesesttesiees 


00:0-00:09:080:6:0:'6 
ry 


epee eae eee a 





© THE ROYAL SOCIETY OF LONDON (PHILOSOPHICAL TRANSACTIONS VOL. 275 NO. 942) 


THE HOME COMPUTER ADVANCED COURSE 1383 


~ FUNCTIONAL 


DESIGN 


AS we continue our Series on LISP, we 
examine the two fundamental concepts 
of the language — lists and functions. We 
show how it is possible to create lists 
within lists, and discuss the importance of 
conditional statements and defining our 
own functions. 


In the first instalment of this series, we saw 

how to inform Lisp that we wanted a particular 

list to be evaluated as a list of data items, rather 
than as a function. So: 


(SETQ X’*(ABCDEF)) 


would assign the list (A B C D E F) to the variable 
X, where each element of the list is a single- 
character string. Let’s see what would happen 
if D, Eand F were single-character strings and 
A, B and C were variables with the values 2, 4 
and 8, respectively. In this case, we would 
really want to assign the list (2 48 D EF) toX. 
We can do this by introducing a new function: 
LIST. This creates a list of its arguments. Thus: 


(SETQ X (LIST ‘A’B’C’D’E’F) ) 


would be exactly the same as the previous 
expression, but: 


(SETQ X LISTABC’D’E’F) ) 


would correctly assign the list (2 48 DE F). 
Here, by omitting the preceding quotes, A, B 
and C will be evaluated. In much the same way: 


(SETQ X (LIST 124 ’(PLUS 4 4) ) 


would assign to X the list (1 2 4 (PLUS 4 4) ) 
where the fourth element of the list is itself a 
list consisting of the three elements PLUS, 4 and 
4. In other words, PLUS has not been evaluated 
because we preceded the expression with a 
quotation mark. However: 


(SETQ X (LIST 1 2 4 (PLUS 4 4) ) 


would assign to X the list (1 2 4 8), where PLUS 
has been evaluated (which is evidence of the 
difference a single quote can make). We can 
extend this concept further to create a list of 
lists. For example: 


(SETQ PERSON ’( (JOE BLOGGS) (17 1 1960) ) ) 


would assign a data list to the variable 

PERSON. This list contains two elements, each 
of which is itself a list. The first list contains two 
character elements and the second list three 
numeric elements. You can continue 
extending this to get even more lists of lists. 
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So far, we have looked at the functions 
SETQ, LIST, PLUS and TIMES. There are many 
more functions built into Lisp, and how they are 
used will depend on the particular 
implementation. In addition, you may define 
your own functions — in fact, this is the way in 
which a Lisp program 1s built. 

Before looking at how this is done, let’s 
examine the three basic functions found in all 
implementations of Lisp. These are CAR, CDR 
and CONS. The name CONS simply stands for | 
CONStruct. The names CAR and CDR date from 
one of the original implementations of the 
language, and are acronyms for Contents of 
Address Register and Contents of Decrement 
Register, respectively. 

CAR and CDR both take a single argument, 
which must be a list with at least one element. 
This excludes the special list structure known 
as the ‘empty list’, or NIL, which is written: 


() 


The function CAR returns as its result the first 
element of its list argument. ‘Thus: 


(CAR ’(1 2345) ) 


would return the integer value 1. ‘There is no 
reason why the result should not itself be a list. 
For example, in the expression: 


(CAR *( (1 2) (34) 5) ) 


the first element is the list (1 2). 

The function CDR effectively returns 
everything but the first element of a list. In 
other words, it returns what is left after a CAR 
operation. So: 


(CDR ’(1 2345) ) 
would return the list (2 3 4 5), and: 
(CDR *( (1 2) (3 4) 5) ) 


would return the list ( (3 4) 5). 

CONS expects two arguments and will 
concatenate them, adding the first argument to 
the second argument list. Thus: 


(CONS 1° (2345)) 





would construct the list (1 2 3 45), and: 
(CONS ’(1 2) ’( (3 4) 5) ) | 
would construct the list ( (1 2) (3 4) 5). e 
The functions CAR and CDR will often be 


found nested, so: 
(CDR *( (1 2) (3 4) 5) ) 
will return ( (3 4) 5), and: 
(CAR (CDR ’( (1 2) (3 4) 5) ) ) 
will return (3 4) which is (CAR ’( (3 4) 5) ), and: 
(CAR (CAR (CDR ‘( (1 2) (3 4) 5) ) )) | 
will return the value 3, which is (CAR ’(3 4) ). | 





This can soon become tedious, so LIsP 
usually allows abbreviations. The function 











names still start with a C.and end with R but 
may have any combination of As (for CAR) and 
Ds (for CDR), in between. Using Acornsoft Lisp, 
this combination may consist of up to three 
embedded letters. Thus we could write the last 
expression as: 


(CAAR (CDR ’( (1 2) (3 4) 5) ) ) 
or: 

(CAR (CADR ’( (1 2) (3 4) 5) ) ) 
or even just: 

(CAADR ’( (1 2) (3 4) 5) ) 


all of which return the answer 3. 


DEFINING FUNCTIONS 


As we've noted already, Lisp programs are built 
up as a Series of functions that are defined by 
the user. We have seen that all Lisp expressions 
are function lists, so quite naturally we use 
functions to define functions. In this case, we 
use the function DEFUN, which expects three 
arguments of the form: 


(DEFUN a (b) (c) ) 


where a is the function name, b is the 
parameter list (as found in PASCAL, BBC BASIC, 
and so on), and cis a list structure containing 
the main body of the function. 

We are now in a position to define our very 
first function. Suppose we frequently wanted 
to multiply numbers by the value 8. We could 
just write: 


(TIMES 8 N) 


‘each time, where N is the number to be 
multiplied. Instead let’s define a function to do 
the same thing: 


(DEFUN TIMES (N) (TIMES 8 N) ) 


Here, the function TIMES takes its argument N 
and uses the standard function TIMES to 
multiply this number by 8 and return a value. 
So the expression: 


(TIMES 11) 


would now give the result 88. 

Before we can proceed further with 
functions, we must examine an important 
programming concept: the condition. Its 
importance can be clarified by imagining BASIC 
without IF... THEN statements! : 

The Lisp condition statement is in the form 
of a function: 


(COND (Condition1 Expression‘) 
: (Condition2 Expression2) 


(ConditionX ExpressionX) ) 


First of all, note that this function has been 
spread over a number of lines to fit it all in. 
This is quite normal in Lisp, which knows when 
you have finished an expression, because you 





will have closed the final bracket. 

The COND function is very much like a 
PASCAL CASE statement (see page 1046). 
Condition is evaluated, and if it is true, then 
Expression1 will be used to return a result. 
Otherwise, Condition2 is tested, and so on. 
Some implementations of Lisp (including 
Acornsoft Lisp) require that at least one of the 
conditions (known as ‘predicates’ ) evaluates to 
true. This is easily handled by adding a final 
condition of the form: 


(COND (Condition1 Expression1) 
(Condition2 Expression2) 


Search Procedure 

This simple data retrieval 
program demonstrates the use 
of the CDR and EQ functions. A 
Car registration number entered 
by the user will, if included in 
the program’s database, return 
a list of two elements — the 
registration number and the 
surname of the car’s owner 


(T Final expression) ) 


Here, the character T is used to represent True; 
so the final expression (if reached) will always 
be evaluated. In Lisp: 


T = True = Not Zero 
and: 
F = False = Zero = () 


The latter is the empty list. We can now define 
a slightly more complex function. 
One very useful feature found in most 


dialects of Basic is ABS, which returns the Test Femctions oo. 
positive value of its argument. In other words, “feoctone — oa 
if its argument is positive, then it will be left ~used in LISP 
unchanged; otherwise it will be negated. Our  . 
Lisp function will have to be of the form: ee 
(DEFUN ABS (X) _._. 
(function body) ) (ONEP arg) 
where X is the integer argument. Using our (ZEROP arg) 
new condition function, we can then write the | ut STP 
complete ABS function as: . a) 
(DEFUN ABS (X) on. | 
(COND ( (MINUSP X) (MINUS X) ) oo) 
We've used two new functions here. MINUSP is a 


a test function that returns the value if its 
argument is a negative number, and false 
otherwise. If the condition evaluates to T, the 
MINUS function negates its argument. If this 
isn’t the case, the T condition (which is always 
true) will return the original value X. 


(GREATERP 

arg? arg2) pews Twe if 
_ —argi>arg2 
(Qagi—s—C 
-arg2) —_— Returns True if 
CC argi=arg2— 
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Daisy, Daisy .. . 

The most usual method of 
connecting MIDI-compatible 
instruments is to daisy-chain 
them together. Most 
instruments have MIDI THRU 
sockets (in addition to MIDI IN 
and MIDI OUT). These 
effectively allow the formation 
of a bus-type system, in which 
all the instruments are 
connected to the bus but only 
respond to messages on 
particular channels 


RULES OF 


COMPOSITION 





Having constructed the MIDI interface 
board, we now turn our attention to the 
equally important aspect of software, which 
will enable us to play ‘real-time’ music. We 
look at information vital to programming, 
examining the meaning of byte format 
values transmitted over the MIDI line. 





We have already seen how a byte of data is 
transmitted via the MIDI to a receiving instrument 
(see page 1035). Now we will determine the 
format of the byte(s) needed to communicate the 
necessary information. 

A single musical ‘event’ is transmitted as a 
group of bytes called a ‘message’. Most messages 
are between one and three bytes long, with the 
exception of ‘system exclusive’ messages 
(discussed later), which may be any number of 
bytes long. Each message begins with a byte that 
has its most significant bit (MSB) equal to one, 
followed by the rest of the message bytes, all of 
which have their MSBs set to zero. A byte with its 
MSB set to one is called a status byte; the others 
are data bytes. MIDI messages are divided into 
two basic types — ‘channels’ and ‘systems’. 

The need for channel messages arises from the 
more usual daisy-chain method of interconnection 
used in small systems. In these, each unit receives 
all the data sent by the master transmitting unit. 

Channel messages are used to transmit 
information that is not necessarily intended for all 
the units in a system. Most MIDI receivers may 
therefore be assigned a channel number, from one 
to 16. 

Channel messages have status bytes with values 
in the range $80 to SEF inclusive, and have one or 
two data bytes. The channel number is encoded 
into the four least significant bits (the least 
significant hex digit) of the status byte with 
channel one represented by $0 and channel 16 by 
SF. The remaining three bits determine the type of 
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message that follows. 
A special feature of channel messages is that the 
status byte need not be sent if it is the same as the 


previous status byte. In effect, the current, or 


running, status remains in force until another 
status byte is received. The exception to this is 
when a system real-time message interrupts the 
current status temporarily. 

This is particularly useful for communicating 
many consecutive note on/off messages, since a 
note onmessage with a velocity (how hard a Key is 
pressed) of zero is equivalent to a note off 
message. Using the same status (note on) for a 
series of note on/off messages results in a saving of 
memory space and transmission time. 

Voice assignment in synthesisers is the process 
of directing a note message (from either the MIDI 
or the instrument’s keyboard) to one of the 
synthesiser voices currently available to actually 
produce the note. For example, a six-note 
polyphonic synthesiser is said to have six voices. 
To control the response of the instrument to 
channel messages, a number of modes are 
selectable by MIDI mode messages. A mode 
message should be ignored by a receiver that is 
incapable of operating in the requested mode. 


MIDI MODE MESSAGES 


Omni mode is the simplest mode, in which the 
receiver responds to all channel messages 
irrespective of the MIDI channel number encoded 
into the messages. When omni mode is turned off, 
the unit will respond only to messages sent on 
specific MIDI channels. 

Most polyphonic synthesisers have a limited 
number of voices (usually six or eight), which 
means that certain action must be taken if a note is 
requested when all the voices are already assigned 
by previous note messages. 

Usually the voices are assigned in strict rotation 
so that the least recent note is turned off to make 
the voice available for the new note. This mode of 























share 


operation is selected by the poly mode onmessage. 
A mono mode on message directs the receiver to 
assign each of its voices monophonically to one of 
a group of consecutive MIDI channels starting 
from the synthesiser’s original (basic) channel. 
The mono mode message is sent on the basic 
channel and its second data byte specifies the total 
number of channels required. 

If omni mode is on, a mono message simply 
directs the receiver to assign one voice 
monophonically to MIDI channel messages on all 
channels. 

System messages are not encoded with channel 
numbers in their status bytes. Therefore, the status 
byte is received by all the units in a system. System 
messages fall into three categories: common, real- 
time and exclusive. 

System common messages have status bytes 
from $F1 to SF7. They consist of the status byte 
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followed by 0, 1 or 2‘data bytes. 

System real-time messages are intended for all 
units in the system. They have status bytes from 
SF8 to SFF and are used mainly by drum machines 
and sequencers to synchronise their own internal 
sequences to the clock in the master transmitter. 
Most synthesisers will ignore these messages 
unless they have some form of internal sequencer 
with the capability of MIDI synchronisation. 

System real-time messages differ from other 
messages in that they all consist of one status byte 
only and no data bytes. As a consequence, they are 
allowed to be sent at any time, even if they 
interrupt messages of other types. 

System exclusive messages begin with status 
byte SFO, followed by any number of data bytes, 
and are terminated by either the end-of-exclusive 
status (SF7) or any other status byte. The first data 
byte is amanufacturer’s identification (ID) code. If 
this does not match the receiving unit’s ID, the 
remainder of the message should be ignored. 

The messages are intended for transferring data 
between instruments of a similar type, which 
would be meaningless to other units. The principal 
type of data transferred is ‘patch program’ data for 
synthesisers. (The transmission of a patch 
program in this way is not to be confused with 
channel message SCx, which selects between patch 
programs already stored in the receiver’s memory. ) 

However, the type of data transmitted by 
system exclusive messages is left to the 


manufacturers provided they have been assigned a 
valid ID code. 
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Star Performance 

Early implementations of MIDI 
did not allow channel selection, 
so all synthesisers would try to 
respond to messages on all 
channels — rendering the 
system almost useless when 
such devices were daisy- 
chained. These early MIDI units 
had to be connected in a star 
formation around a mother unit, 
which incorporated circuitry so 
that each channel could be 
obtained from a separate OUT 
socket 
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A UTTLE 
PEACH 


Although the Apricot Fle is mtended 
primarily as a business machine, it is likely 
to be very appealing to the educational and 
small business markets as well. With its 
entry price of £684, the Fle comes well 
within the price range of the serious home 
computer user too. 


The basic setup of the Fle will be easily 
recognisable to those familiar with Apricot 
computers. Sold as a package, it includes the F1 
keyboard, the computer unit itself with a single- 
sided single-density disk drive, and an eight-inch 
‘sreen screen’ monitor. As with the Apricot 
Portable (see page 1109), the company has 
included its infra-red technology, which removes 
the need for a large number of trailing leads. Both 
the-keyboard and the optional mouse control the 
computer via infra-red beams that are detected by 
sensors on the front of the Fle. Reflecting the 
trend towards smaller computers (initiated by the 
Apple Macintosh), which do not take up large 
amounts of desk space, the Fle is remarkably 
narrow, measuring only 200mm (8in) across, 
although this is somewhat offset by the length, 
which is around 425mm (17in). 

The keyboard is in the standard Apricot layout 
— the keys are flush and similar in appearance to 
those on the Sinclair OL. The keyboard is not 
particularly good for touch-typing, and therefore 
not very well suited to word processing 
applications. The keys themselves, while adequate 
for a modern business machine, rattle a bit and 
might raise suspicions concerning their long-term 
reliability. Like the Apricot Portable, there are 
four buttons at the top of the keyboard: ‘Reset’, for 
cold starts, ‘Repeat Rate’, allowing you to vary the 
rate at which characters are repeated when a key is 
held down, ‘Set Time’ and ‘Keyboard Lock’. 

The computer unit has a single Sony 37in disk 
drive, built into the front, which is becoming 
increasingly popular with manufacturers and has 
therefore justified ACT’s early use of this format 
for its machines in more ways than one. While 
some other companies are having difficulties 
transferring their wide software bases onto the 
3tin disks, all Apricot software is conveniently 
compatible. Users wishing to purchase the Fle 
therefore have no need to worry about a lack of 
suitable software. Furthermore, the single-sided 
single-density disks used with the Fle can hold a 
maximum 315 Kbytes of information, more than 
their 5zin counterparts. 

Other features on the front of the computer unit 
include a series of LEDs indicating power, Caps 
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APRICOT le- HARDWARE 


Lock, scroll and drive on/off. Beneath these are 
the infra-red light beam detectors. 

On the right-hand side of the computer is a 
60-way expansion bus, through which a wide 
range of expansion boards, or an extra disk drive, 
can be added. This slot makes the Fle expandable 
to the capacity of the Apricot XI by adding the 
MSD expansion system, which provides 10 
megabytes on hard disk. 

The rear panel, while not having many 
interfaces, is sufficiently well-designed to allow 
the more common peripherals to be fitted. On the 
far-left is a standard 25-way D connector that 
accommodates an RS2372 serial interface. Next to 
this port are two monitor sockets. The first is a 
nine-pin adaptor that provides an RGB signal for 
colour monitors (although the monochrome ACT 
monitors that are available also plug into this 
socket). To the right of this is a composite video 
socket for other types of monitor. 

The £684 price of the Fle does not include a 
monitor. The computer does not have an RF 
adaptor enabling it to send a signal to a standard 
television set; however, there is an adaptor 
available to provide such a signal. Also, since a 











Good-Looker 

The Apricot F1e has inherited 
the good looks of its relations. 
The integral 32 in disk drive, 
standard MS-DOS operating 
system and bundled software 
packages, together with a price 
tag of under £700, make the Fle 
a serious challenger to the BBC 
Model B and B+ systems, which 
are currently favoured in 
educational circles and by the 
serious home computer user 


THE HOME COMPUTER ADVANCED COURSE 1389 


monitor is not fitted as standard to the Fle and 
many monitors have their own power input, the 
monitor sockets do not automatically provide 
power lines, and the computer itself is not capable 
of providing such a source. Therefore, an external 
17v power supply has to be fitted to the computer 
to enable it to run one of ACI’s monitors. 

Although this seems logical enough, the fact 
that ACT has made the decision to remove the 
usual trailing wires by providing infra-red 
communications is at odds with its decision to 
provide an external power supply to run its 
monitors. This is especially so since other models 
in the range (like the company flagship ACT 
Apricot) do not require such a device. The power 
supply can be tucked out of the way, especially if it 
is set up in a permanent position, but you are still 
left with the impression that this aspect of the 
machine was hastily thought out. 

Inside the computer, there is a further 
expansion slot for extra boards. The F1e’s board, 
in common with others in the Apricot range, is 
elegantly designed and is entirely protected from 
the disk drive and power transformer (which can 
generate harmful temperatures) by a metal casing 
that acts as a heat sink. 

The Fle is based around the 16-bit 8086 
processor and runs under the popular MS-DOS 
operating system. Apricot computers, however, 
have always had their own _icon-based 
management system, which means, in effect, that 
you will have little to do with the operating system 
directly. The management system on the Fle is 
known as Activity, and it is with this that users will 
become most familiar. 

Activity is an object-oriented program. This 
means that rather than issuing a series of 
commands to the computer, such as one to LOAD a 
file into memory, you merely indicate (generally 
by selecting an icon from a series presented on the 
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screen) which action you wish to perform; the 
computer will do the rest. 

Most of these systems depend on the use of a 
mouse to move the cursor around on the screen, 
but on the Fle system, the numeric keypad can be 
substituted. The figures 1 to 9 are arranged in three 
rows of three keys. Taking the keypad as a 
compass (excluding the centre key) there are eight 
directions in which the cursor can be moved. Thus 
pressing the middle Key of the top row (8) will 
move the cursor straight upwards to an icon in that 
direction, whereas pressing 3 (the right position on 
the bottom row) will move the cursor diagonally 
down to the right. To select an icon you have to 
press the Enter key on the calculator keypad. 

Among the suite of programs included on the 
Activity system disk is a tutorial program to help 
accustom you to the system. It also explains the 
usages of the icon and fount editors (with facilities 
to load your own character sets whenever you 
choose) and the system configurator, which allows 
you to set up the computer for whatever 
specialised peripherals you may be using. 


THE BUNDLED SOFTWARE 

As you might expect from the Fle, which is 
intended primarily as a business machine, it has 
several software packages included in an 
applications pack. SuperWriter is a word 
processing program based around the widely used 
WordStar, but without the latter’s breadth of 
formatting capabilities. SuperPlanner is described 
as an ‘electronic notebook’ that allows you to 
‘forward-plan’ your activities. Included within this 
program is an address book, a calendar, a diary 
and a small filing system. Although superficially 
resembling a database, SuperPlanner does not 
contain the sophisticated search and retrieval 
techniques present on a true database. 

The final package bundled with the Fle is 
SuperCalc. This is a spreadsheet for financial and 
accounting applications. This is perhaps the most 
complete of the three packages, containing a wide 
number of commands allowing windows, text 
justification and a number of other features you 
would expect from a professional spreadsheet 
package. 

In reducing the price of the Fle, ACT has let the 
computer industry know that it intends to make a 
concerted push into the educational market. This 
is emphasised by the fact that along with the 
announced price cut, ACT released a new product 
called B-TRAN, which enables the computer to 
run virtually all programs written in BBC Basic. 

The reduction in the price of the Fle will 
certainly improve the sales of the computer, 
particularly in the educational and small business 
markets, which have so far been dominated by the 
BBC Micro. Although it is not likely to dominate 
the home computer market in the same way the 
Sinclair Spectrum has, the Fle is nevertheless an 
excellent purchase for those interested in buying a 
low-priced machine that can be expanded to the 
power of a fully-equipped business computer. 
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Rise And Shine 
This diagram shows the 
development of a pulse wave. 
Note that the change from Ov to 
the maximum does not occur 
instantaneously, but rises over a 
period of time. The rise time is 
measured by how long it takes 
for the pulse to change from 
10% to 90% of its maximum 
(and vice versa for the decay 
time) 





PROMPT 


This is a character or message displayed on a 


_ television or monitor screen, when a computer is 
expecting some input from the user. Often the 


prompt will indicate what kind of data it is 
expecting to receive (for example, whether the 
computer expects numeric or alphabetic input). 
Prompts can also tell us something about the 
status of the computer. When we are running a 
computer under one of the popular disk operating 
systems, such as CP/M or MS-DOS, the prompt 
will appear as A>. This tells us that the currently 
logged drive is A and that any command that is sent 
for execution (unless specified otherwise) will be 
expected to operate on the disk in that drive. 


PROTOCOL 


When data is transmitted between two devices, 
there must be a set of rules that govern the 


exchange of information. This set of rules is. 


known as the protocol. The kinds of parameters 
that are set by the protocol include the 
transmission speed, the amount of data to be sent 
at once and information about how to identify the 
receiving device, how the data is received and in 
what form it is to be transmitted. The protocol will 
also dictate how the data is to be checked for 
errors, as well as define the method of requesting 
retransmission in the event of an error. 

A system of protocols is used when accessing 
public databases. In this case, the protocol sets the 
baud rate, the method of transmission (ASCII 
codes) the start and stop bits — which indicate the 
boundaries of a separate piece of information — 
and the parity checking, which informs the target 
computer whether the information has been 
received correctly. 


PULSE 
A pulseis defined as a rise (usually relatively large 
and rapid) of the amplitude of an electrical 
current, sound or electromagnetic wave, followed 
after a short period of time by a corresponding 
drop in the amplitude. In electronics, the change in 
amplitude usually refers to a change in the voltage. 
‘The parameters governing the shape of a pulse 
are as follows. The rise timeis the period taken for 
the amplitude to rise (this would be almost 


1392 THE HOME COMPUTER ADVANCED COURSE 


instantaneous in the case of the pure square wave) 
until it reaches the pulse height. At this point, the 
amplitude will be maintained until it begins to fall 
back to the original value. This section is therefore 
known as the decay time. The time between the 
beginning of the rise of the amplitude and its 
subsequent return to the original value is known as 
the pulse width. 

The generation of pulse waves is fundamental 
to the working of most computers. An example of 
the use of sharply defined pulses within a 
computer is the system timer. Here, a highly 
accurate ‘clock’ is required in order to synchronise 
the system operations. The rise and delay times, 
which trigger the actions of the processor, are kept 
extremely short in order to ensure that the cycles 
are kept as regular as possible. 

The invention of the transistor had a 
fundamental effect on the development of digital 
computers based around the pulse wave. A 
property of many transistors is that they will not 
allow a current to pass unless the voltage 
(potential difference) reaches a certain value. The 
transistor will then transmit the current until the 
voltage falls once more below that value, when 
transmission will cease instantly. The resultant 
effect is a pulse wave. 

Another major use of the pulse in 
microelectronics is in the production of 
synthesised sound. The square wave is an 
important component of many electronic 
instruments, and is used to add a ‘harder’ tone to 
many sounds. 


PUNCHED CARD 


Although they are now largely obsolete, punched 
cards were once widely used for inputting data into 
computers. A standard card measures 18.75 by 
8.25cm and is divided into 12 rows and 80 
columns, though there have been many variations. 
Combinations of holes represent particular 
characters. These are sensed by a ‘card reader’, 
which translates them into digital signals that the 
computer can understand. 

The keyboard, magnetic tape and disks have, 
for the most part, replaced the punch card, but it 
has left some influence in the computing field. The 
programming language copo_, for instance, will 
not accept a line over 80 characters in length, a 
reminder of the 80-column cards for which the 
language was developed. 

The notion of storing data on punched cards is 
one of the oldest ideas in computing. Herman 
Hollerith, inventor of the familiar punched card 
and founder of the company that became IBM, 
developed his system at the end of the last century. 
Before him, Charles Babbage, often referred to as 
the father of computing, believed that the method 
was ideal for storing data in the ‘analytical engine’ 
he invented, as long ago as 1822. The earliest 
example, however, stems from 1802, when Joseph 
Jacquard built a loom that recorded the patterns of 
fabrics on what were, for all intents and purposes, 
punched cards. 
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SET-UP SHOTS 


When writing a program for a game like Go 
it is always best to begin with the I/O 
routines. We start our project by outlining 
these routines for the BBC Micro — 
initialising variables, producing the Go 
board on screen and providing a list of the 
variables and their usages. 


The Go program will be presented in four separate 
versions: for the BBC Model B Micro, the 
Commodore 64, the Sinclair Spectrum and the 
Amstrad CPC 464/664 micros. Where possible, 
the line numbers in these versions have been kept 
consistent, but for various reasons extra lines have 
been needed to implement some routines on the 
different machines. This is especially evident 
where recursion has been used in BBC Basic 
(recursion is not implemented on the other three 
machines). 

Consequently, it is necessary to implement a 
user stack in order to keep the listings as similar as 
possible. When the text refers to routines and 
variables in the listing, these will apply to the BBC 


GO/PROGRAMMING PROJECTS 





Opening Move 


Traditionally the game of Go is played on a wooden board 


etched with a 19 by 19 grid of intersecting lines. In our 
computerised version of the game, we have reduced the 
board size to a 15 by 15 grid to allow the board to be easily 
displayed on a VDU screen 


Micro version, though cross-referencing between 
the four listings is quite straightforward. 

The following section of program deals with the 
initialisation of variables, creating the board 
display and providing the input routines. Lines 10 
to 140 constitute the main body of the program. 
Before entering the game loop itself (lines 60 to 
90), the routines PROCinitialise and 
PROCintroduction will be called. 

PROCinitialise is only used when first running the 
program to DliMension the board (board), 
initialise the cursor and so on. The board is 
DIMensioned to be a series of 255 bytes, creating a 
15 by 15 playing area (rather than the usual 19 by 
19 Go board). 

There are a number of reasons for this, the most 
important of which is speed. A BASIC game- 
playing program cannot be expected to operate 
particularly quickly, but by reducing the size of the 
board, execution time will be cut by about one 
third without affecting the way in which the game 
is played. Of course, this also means that the board . 
fits neatly into one page (256 bytes — one quarter 
of a Kbyte) of memory, allowing for a boundary 
made up of single squares. By ensuring that all 
board references are in the range 0 to 255, this 
border will encircle the entire board. 

The variables initialised in lines 190 and 200 are 
constants, but by using the variable name instead 
of the actual numbers, modification is made much 
easier. For instance, if you wanted a two-player 
game, or the computer to play itself, you would 
only need to change the values of black% and 
white% in order to use all the routines normally. 
Based on these values, each board byte will be 
used in the manner shown in the diagram. 

PROCintroduction is used at the start of each 
game, to set up the move counter (move%), the 
end condition (end%), and so on. This makes use 
of the routines PROCgame_init and PROCtitle_screen. 
The title screen is fairly elementary due to space 
restrictions for the listings, but you should feel free 
to modify this as much as you want. For instance, 
you could add the Japanese Go symbol, or 
possibly a few strains of Oriental music. If youd 
like to add pieces of your own code, all line 
numbers from 5000 onward are free for this. 

PROCprint_board, naturally enough, prints the 
board. FNint_to_ char is used from this routine to 
convert an integer board co-ordinate into the 
character co-ordinates used by the screen display; 
it is DEFined at line 2260. 

FNinput and PROCmessage are two general- 
purpose routines for user input and message 
printing, based on the mess§ array initialised in 
PROCread_messages. This array holds 10 prompts 
or messages that the computer needs to display 
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Go Game: 
Variables 


during the game. The appropriate message is 
selected by passing the corresponding array 
element number, M%, to these two routines. 
Incorporating these routines, rather than just 
prompting and receiving input and output when 
needed,,increases the flexibility of the program. 

One problem you may have when typing in the 
Spectrum version is between lines 1480 and 1505. 
The underlined numbers in these lines refer to the 
Spectrum’s symbol graphics. You'll get these by 
first pressing Caps Shift and 9 together, thereby 
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entering graphics mode (the G cursor), and then 
typing the numbers shown. Press Caps Shift and 9 
again to leave graphics mode at the end of the print 
statement. If the number is preceded by sh, then 
type the number while pressing a Shift key. 

If you run the code as it stands, you'll get a title 
screen asking for a number of handicap stones, 
followed by the main game screen. The program 
will then loop indefinitely. The handicap number 
is ignored at present, but we'll add this and a few 
more general routines in the next instalment. 

















NUMBER OF COMPUTER'S BOARD PLAYERPROMPT MOVE 
STONES CAPTURED LASTMOVE DISPLAY AND ERROR NUMBER 








ASEH 


JAN McKINNELL 


Type your move Ceg. H&>, PASS or 
QUIT : 


Running Commentary 
The screen display above shows the layout of the various 
features of the game. In addition to showing the board, the 
program informs the player of the number of stones captured by 
both the computer and the player, the number of moves played 
so far in the game, and states what were the last moves made by 
the computer and its human adversary. The bottom portion of 
the screen is reserved for prompt and error messages to the 

~ player. As the game is developed we will see how the program 

detects and disallows illegal moves such as ‘suicide’ or any 

attempts to place stones on positions that are already filled 







































Bits On Board 
Each position on the board is 
represented by a single byte in 
memory. The upper diagram 


shows the layout of the 255 


bytes that represent all the 
intersections on the 15 by 15 
board. Bits within each byte 
hold information about the state 
of the corresponding 
intersection on the board. The 
two least significant bits 
determine the colour of the 
stone present (or indicate 
whether the intersection is 
vacant). Bits 2 and 3 will be 
used by ‘game-state’ evaluation 
routines developed later in the 
project 
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To conehides our a ie a series on program 
generators, we look at the fundamental 
operating procedures for two of the most 
popular packages currently available — 
Sycero and The Last One. By stressing 
organised pre-planning, these systems will 
help you to generate concise and bug-free 
programs in BASIC. 





Any software chaning to onnele ite ennialete 
beginner to generate computer applications must 
satisfy some stringent parameters: 


@ It should encourage a ‘top-down’ approach, 
with which the user maps out the project in outline 
and more clearly defines each point as the work 
continues. 

@ [t should be menu-driven, with multiple-choice 
prompts that guide the user through the available 
options. 

@ [t should trap errors as they appear and allow for 
simple amendments or second thoughts. 

e'The resulting code should be ‘transportable’ — 
able to run on another computer independent of 
the system software that generated it. 

@ [t should produce ample documentation of the 
process of program generation, so that a user 
unfamiliar with the preceding programming can 
introduce further amendments or enhancements. 


However, since the program generator is a tool 
whose use is not restricted to the uninitiated, it 
should also be acceptable to the more experienced 
user. A program aimed at too low a level is likely to 
infuriate and possibly even confuse the more 
advanced user, as well as delaying things with 
_ unnecessary safeguards and foolproofing. The 
-more experienced user is also likely to have 
favourite routines — ways of using sasic, for 
example — which the generator should be 
prepared to accept. On all these counts, the most 
popular program generators, The Last One 
(TLO) and the newer Sycero, both score high 
marks. | 

Informative menus are used throughout in 
both. Sycero has help screens concerning such 
features as cursor controls and graphics; text 
editing commands are available at any time by 
pressing the Control and H keys. Of the two 
systems, ILO more closely adheres to the top- 
down approach. It starts by working out a 
‘flowchart’, which is actually a series of REMarks 
about what each section of the program is 
intended to do (Branch on 4-option menu, for 
example) and can be incorporated in the final 
BASIC program if required. 
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PLANNING 
THE ACTION 


Input and display screens are defined during the 


program coding process and the resulting code will 


be in ASCII format. The user then has to exit the 
generator, LOAD the generated program, and re- 
SAVE it in binary code. In Sycero, file definition and 
screen design are the first things the user takes care 
of. This is followed by ‘input variable processing’ 
(associating help prompts and error messages with 
the relevant user input), report definitions and 
several other options. The various modules will be 
linked together just prior to coding. 

Although this approach is less friendly to the 
inexperienced user, it has the advantage that it 
requires the project to be carefully defined before 
it is coded or it won't run at all. Furthermore, if the 
generator spots any errors while it is coding, it halts 
the process and informs you of the error so that 
you can correct it. The coding process concludes 
by saving the program, in binary file, which can be 
run from within the Sycero environment. 

Both generators produce fully transportable 
code. In fact, if the TLO program is short enough, 
it should be possible to run the ASCII version on 
an MSX-standard machine (as long as it stays 
within the micro’s memory limitations). However, 
both programs include very complex and 
comprehensive error-trapping routines within the 
programs they generate, making them rather 
bulky. 


CERTIFYING A WORKDISK 
As is common with MS-DOS software, both TLO 


and Sycero must be configured to the hardware in 


use with Install programs, which can be used with 
dual-drive floppy or hard disk machines. TLO 
must also ‘certify’ a workdisk, a process somewhat 
like formatting. For this purpose, a workdisk can 
either be an entire floppy disk or a sub-directory 
on the hard disk (the latter is certified as part of the 
installation process). The certification is essential, 
because if the program cannot detect a workdisk 
area during flowchart amendment, it will be 
unable to find the relevant flowchart. This will 
mean you will have to go back to the beginning or 
attempt to manipulate the Basic code. As usual, 
you can protect against this kind of disaster by 
frequently making back-up copies of the contents 
of the disk you are using. 

Both TLO and Sycero generate profuse 
documentation, listing such matters as the screen 
design characteristics, the variable names used 
and so on. Sycero adds the date and time on screen 
as well as on printed copy so that you can 
distinguish between early versions and _ later 
upgrades when checking. 

After installation, the TLO user is offered an 
eight-option Main Dispersal Menu: 


Create a program Enquiry 

Modify a program Certify new disk 
Modify a file Resume coding 
File definition Return to BASIC 


After choosing the first option and answering the 
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. .Branch on a 3-option menu 

. .set pointer to the end of Address file 

. .Keyboard input for Address file 

. .Write data to Address file 

. .ASk < Have you finished? >. Branch if ‘No’ 
. .Direct unconditional branch 

. .Branch on a 3-option menu 

. .Set pointer to the start of Address file 

. .Keyboard search of Address file 

. .Display data from Address file 

. .AASk <Another search? >. Branch if ‘Yes’ 
. .Direct unconditional branch 

. .ort Address file 

. .Set pointer to the start of Address file 

. .Read data from Address file 

. .Display data from Address file 

. .Direct unconditional branch 

. .Jerminate 
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Coding can then commence. Until this point, you 
have not been able to drop out of the program 
without losing all the work done so far. As soon as 
coding has begun, however, it will be possible to 
quit and use the Resume coding option to re-start. 
During coding, the destinations of branches are 
completed — the first menu, for example, will 
branch to 2 (write data), 7 (read data) or 18 
(terminate) — and the screens are designed. 

It is possible to SAVE screens, which is advisable, 
since they can be modified for later use elsewhere 
in the program or in other programs. However, 
there is nothing in the software or the manual that 
gives this feature the emphasis it requires. In 
Sycero, screen SAVEing is automatic. 


SYCERO’S OPENING MENU 


Sycero’s opening menu offers 13 options that are 
used in more or less the order they appear: 


system configuration 

Initialisation . 

system file-field definition 

screen definition 

Screen processing 

Report definition 

Report processing 

Program definition 

Generate a program 

Create a ‘live’ data file 

Run a generated program 

Utilities 

End session | 
By the time you have reached the program 
generation option much of the work will have 
already been done, and the fairly simple process 
that follows will require little intervention, unless 
the software detects an obvious error. Of course, it 
cannot deduce your intentions, so it is imperative 
that you instruct the system in a precise manner. 

The main difference between the two 
generators is one of approach. As the Sycero 
manual says itself, “The best way to develop a 
system is to use the top-down approach. Start with 
the broadest of outlines, and then gradually fill in 
the details from the top down. Unfortunately, the 
best way to enter the details into a generator is the 
other way about, bottom up’. 

Because it starts with a flowchart generator, 
TLO is closer to this classic top-down approach, 
though paradoxically it may thus encourage the 
user to start work with inadequate pre-planning. 
Sycero, on the other hand, is virtually unworkable 
unless you pre-plan, though it makes it easier to 
revise things as you go along. 

Sycero and TLO both provide the user with a 
convenient way of generating programs in BASIC to 
run independently on the host machine. Despite 
their limitations they can prove useful for the 
construction of database utilities and simple 
question and answer calculation programs — 
although any code generated will be considerably 
bulkier than an equivalent program written from 
BASIC. 
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~ HOOK LINES 


Inner Workings 
We show here the principal 
components of the printed 
Circuit board of the Interface 1. 
Apart from providing 
Microdrive, serial interface and 
LAN facilities, it also makes 
possible the addition of extra 

- BASIC commands defined by 
the user. We will discuss user- 
defined BASIC commands later 
in the course 








1 to the Sinclair 





The addition of Interface 


Spectrum not only gives access to the 
Microdrive, a serial interface and local area 
network (LAN) facility, it also provides us 
with a few machine code routines that we 
can make use of in our programs. Here, we 





which occupy the first section of memory. It 
provides the necessary routines to drive the 
various additional devices (such as Microdrives), 
as well as extending the Basic interpreter to accept 
such commands as CAT and FORMAT. This ROM is 
usually called the Shadow ROM. 

There have been several different versions of 
this ROM, and there are major differences 
between the initial implementation (Version 1) 
and the one currently being produced (Version 2). 
Version 1 was rather inefficient in its use of 
Microdrives, and several of the operations that 
were supposed to be available were not. 

Later versions of the ROM are more efficient in 
handling Microdrives, allowing us to use more of 
the space on a Microdrive cartridge. Also, the 
bugs were eliminated, and a couple of new 
facilities for use with serial printers were 
incorporated. 

These ROM _ differences are generally 
‘transparent to the user, provided that the 
Interface is accessed using BASIC or the approved 
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machine code programming _ techniques. 
However, should you attempt to call Shadow 
ROM routines directly, youll probably have 
problems because different routines are located at 
different addresses in the various versions of the 
ROM. Any specific Shadow ROM addresses that 
we give will be for the Version 1 ROM. 7 

How does the Shadow ROM occupy the first 
eight Kbytes of memory space when the BAsiIc 
ROM «is also in this area of the memory map? Well, 
a technique similar to the paged ROM system of 
the BBC Micro is employed. Whenever the Z80 
attempts to read an instruction from addresses &08 
or &1/708 with Interface 1 connected, the BAsic 
ROM is momentarily ‘paged out’ and the Shadow 
ROM takes over for future operations. There is a 
routine in the Shadow ROM to reselect the main 
BASIC ROM when the time comes. 

Before any of this can happen, however, 
Interface 1 must be initialised. This is carried out 
when: 


1. A NEW command is issued with the Interface 
attached. 
2. The Shadow ROM is paged in for the first time. 


The practical result of this initialisation process is 
that a new group of system variables are set up. 
These occupy RAM from the end of the old 
system variables to the start of the Channels area 
— over 50 bytes of space. This, combined with the 
setting up of the Microdrive map and other 
information needed by the various devices 
supported by the Interface 1, is responsible for the 
fact that with this Interface connected the start of 
BASIC program text is moved up in memory. This is 
why it is ill-advised to store machine code in Line 1 
REM statements once the Interface is connected 
(because Line 1 of the program is no longer at a 
constant position in memory). 

As we have already mentioned, Interface 1 also 
gives us additional BAsic commands. Indeed, we 
can even add our own, as we'll see in a future 
instalment of the course. However, at this point 
we'll just take a simplified look at how the 


‘commands such as CAT and FORMAT are 


implemented. On the unexpanded Spectrum, 
these would fail the various checks made by the 
BASIC interpreter, and so in normal circumstances 
will generate an error. This is done by the use of the 
RST &08 instruction, thus accessing address &08. 
When Interface 1 is connected, however, this 
instruction will page in the Shadow ROM, which 
will give the offending piece of BAsic a ‘second 
look’ to see if it’s a command that it can interpret 
correctly. If it can, it will do. Commands such as 
the following, which saves the program called Fred 








i 
} 
| 


to Microdrive, function in a similar fashion. 
SAVE *“m”:1;“Fred” 


The * part of the command generates an error 
condition, thus causing control to pass to address 
&08 — and hence into the Shadow ROM, where 
correct interpretation of the statement occurs. 
Let’s now look at the additional machine code 
routines that are provided by Interface 1. We'll 
examine what could be called the ‘general 
purpose’ routines — those Shadow ROM routines 
that are not concerned with the control of the 
Microdrive, the serial interface or LAN facilities. 


HOOK CODES 


The first problem is calling these routines; the 
Shadow ROM is only active after a call to either of 
the addresses we mentioned earlier. We solve this 
by making a call to address &08 using the following 
instructions: 


RST &08 
DEFB nn 


where nn is a value between &1B and &82 (values 
outside this range generate error messages). These 
values of nn are called hook codes, and each of 
these calls a different Shadow ROM routine. The 
effects of the hook codes have remained 
unchanged in the different versions of the Shadow 
ROM. Before we take a look at some of these calls, 
there are a few points to note. 


1. The hook code operations tend to corrupt all the 
registers, so it is necessary to preserve the registers 
that youre going to use after the call. In addition, 
it’s a good idea to save the HL register pair, as this 
is important for a safe return to BASIC. 

2. Certain of the hook code routines will turn off 
the interrupts. Re-enable these if youre not 
certain. 

3. When a hook code call is used, have the value 
&5C3A in the IY register pair. 

4. Before a hook code is used, it’s a good idea to 
ensure that the Interface 1 system variables have 
been set up. There is, in fact, a hook code to do this 
job for you, and we'll look at this one first. 


@ Hook Code 49 (&31) is responsible for the 
creation, or insertion, of the Interface 1 system 
variables. If you're not certain whether these have 
been created, then you should issue the following 
call before attempting to use any of the other hook 
codes: 


RST 8 
DEFB = 49 


Once a hook code routine has been executed by 
the Shadow ROM, then control is passed back to 
the main ROM. 

The Shadow ROM also provides us with some 
routines that are present in a less convenient form 
in the main BASIC ROM. These deal with input and 
output to the screen and from the keyboard. 


@ Hook Code 27 (& 1B) waits for a character to be 
typed in at the keyboard, and then returns the 





character code of the key pressed to the A register. 
(Note that nothing is printed to the screen.) 


® Hook Code 32 (&20) examines the keyboard at 
the instant it is called and indicates — via the status 
of the C Flag — whether a key is being pressed or 
not. This routine doesn’t wait for a key to be 
pressed. If a key is being pressed, then the C flag is 
set to one; if nothing is pressed then it is set to zero. 
It’s vital that interrupts are enabled before 
calling hook codes 27 and 32, as the keyboard 
scanning on the Spectrum is interrupt-driven. 


® Hook Code 28 (&1C)is responsible for printing 
the character (indicated by the ASCII code held in 
the A register on entry to this routine) to stream 2, 
which is usually the upper portion of the television 
screen (see page 1332). The use of this routine, 
and hook code 27, is shown in the following piece 
of code. If you enter this program, note that it is a 
permanent loop, and so you'll have to turn the 
machine off to get out of it. 


jcall routine in Shadow Rom - use with care! 
218868 Id hl, ADDRESS sinsert address of routine 
22ED5SC Id (23789) ,hl jput address in system variable 
CF rst #68 
32 ‘  defb #32 do it 


® Hook Code 31 (& 1F) is similar to hook code 28, 
but writes the character (with ASCII code in the A 
register) to stream 3 — usually the ZX printer. 


® Hook Code 50 (&32) is the final general 
purpose hook code that we'll look at here. ‘This is 
rather mysteriously labelled Sinclair Research Use 
Only in the specifications. This allows us to call a 
Shadow ROM routine at a particular address from 
the main ROM, rather than by using hook codes. 
Because of the differences between versions of the 
shadow ROM any programs that use this call to 
access is placed routines will crash if they are used 
on another version. However, we include details 
here for the sake of completeness. 


The address of the Shadow ROM routine we 


want to access is placed in two addresses in the 
system variables produced by the Interface 1. The 
address of the variable concerned is locations 
23789 and 23790. The hook code call is then made. 
The following section of code will do this: 

wait for char, print to stream 2 

jHook Codes #1B and #iC 
CF start: rst #68 sset up Interface i... 
31 defb #31 ;.. system variables 
FR sloop: = ei yei - just in case 
swait for a char... 
1B defb #18 ;...from the Keyboard 
CF rst #08 ;char now in A reg... 


IC defb #iC +...50 print it 
18F9 ir lieop yround again ad infinitum 


This isn’t a terribly useful call unless you know 
what the various Shadow ROM routines do and 
which versions of the Shadow ROM youre 
working with. However, we will examine this call 
in a little more detail when we come to discuss how 
we can use Interface 1 to add new instructions to 
BASIC. In the next instalment, however, we'll look 
at those hook codes that are specific to Microdrive 
operations. 
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ne less capable cassette. 
S reason, almost all British adventure 
software i is RAM-based and, consequently, rather 
limited, although programmers have become 
adept at exploiting the limited space available. In 
particular, the development of ‘interactive 
characters’ (which require large amounts of data) 
has been held up, as has the introduction of games 
with large vocabularies. 

In the United States, however, the situation is 
very different. All popular home micros have disk 
systems readily available, and the generally higher 
levels of disposable income have meant that such 
systems are almost always purchased by the first- 
time user. The market has therefore been ideal for 
the development of complex adventure software 
or, as some prefer to call it, ‘interactive fiction’. The 
American software house Infocom has been a 
leader in providing for this market. 

The latest product from the Infocom stable is 
typical of the high standards now expected from 
the company. A collaborative venture between 
Infocom programmers and Douglas Adams, The 
Hitch Hiker’s Guide to the Galaxy is now available 
in this country for a range of machines, including 
the Apple Ile and the Atari range of computers (a 
version for the Commodore 64 will shortly be 
available). It requires a single disk drive and a lot of 
patience. 

The game is closely based on the series 
originally written for radio by Douglas Adams, 
and features such characters as Ford Prefect, 
Zaphod Beeblebrox, numerous aliens, and, of 
course, Arthur Dent, the anti-hero of the story 
who finds himself one day plucked from suburban 
existence and spirited away into deep space inside 
the hold of a Vogon Starcruiser. 

The first and most obvious strength of the game 
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traditional ie and nouns to which most British 


adventure games are limited. Furthermore, the 


vocabulary is extremely large — between one and 
two thousand words — and input can be in a 
number of different formats. For example, you 
can enter a direct command (such as Drink the beer), 
a multiple command (Take the babel fish then put it in 
the pocket), or even a direct question (Where am I?). 

Characters can be addressed by simply saying 
their names, as in Ford, where are we? or Marvin, go 
away. Even if the computer doesn’t understand 
exactly what is intended of it, the program will 
usually come up with an acceptable response — a 
great improvement on the traditionally British You 
can't do that or just | don’t understand. 

Other programming techniques incorporated 
into this game include the provision of ‘containers’ 
(objects that can hold other objects), a facility 
often missing from British games. Other 
provisions are ‘global objects’ (such as ‘floor’, 
‘wall’ and so on), which may be present in many 
different locations, and ‘vehicles’, containers that 
can hold and carry the player from one location to 
another. It is interesting to note, however, that 
most of these facilities, together with the large 
vocabulary and efficient parser, result from the 
increased data storage provided by disks, rather 
than clever programming. 

Disassembling an Infocom game reveals a very 
complex plot and script design, but little in the way 
of what we have come to call artificial intelligence. 
There is a strong view amongst some British 
adventure programmers that the luxury of disk- 
based programming has made their American 
colleagues somewhat lazy, and that when the 
British market abandons cassettes, the 
compression techniques developed for RAM- 
based games will result in superior programs. 

The Hitch Hiker’s Guide to the Galaxy will 
undoubtedly provide many hours of playing time, 
and is as full of surprises and humour as the 
original radio series. 




















